ウェブサイトの構築 ~コンテンツ管理~

最終更新: 2025年7月27日 23:08

ウェブサイトの構築 コンテンツ管理

目的

ウェブサイトの訪問者が、目的の情報までたどり着きやすく、見やすく、読みやすくしながらも、運用する側も情報を届けやすく、コストを抑えつつ、管理しやすく、労力をかけずにに運用できるようになること。

CMS

ヘッドレスでもWordpressでも何でもいいけど、APIでデータを取得・更新できるのが必須。あとはマークダウンで管理できるもの。

マークダウンでのコンテンツ作成

持ち運びのしやすさ

CSSを書けない、コンテンツの階層構造は維持しつつも移行先のDOMに順応させやすい。移行時に修正をかけるとしても対象箇所をルールベースで識別できるので一括処理可能。

アクセシビリティ対応・デザインの統一

コンテンツ作成者が勝手にスタイルを作れない。コンポーネントで用意されているスタイル以外が適用されることが起こりえない。 スタイルの崩れが生じている際にも、責任分界点が明確であり、問題点の発見も好き勝手に作られているのと比べるとしやすい。

AIに読ませやすい

タグがない分、トークンが減ること、分量が減るので、精度に多少貢献しやすい。

考慮事項

埋め込み

Google Map, Youtube、iframeなど、それに対応するコンポーネントをわざわざ作るか、もしくはHTMLを直で書かないといけない場合を考慮して、その場合には担当部門の承認を経たうえで公開可能とするか、、、 外部サイトの埋め込みをする場合は管轄部門の承認を必要とした方がいいかも。

作成から公開まで

多言語対応

AIにリクエストを投げて翻訳させてもいいかも。チェックは必要だけど。 同一コンテンツについては、slugを確保してURLが同一のコンテンツを指し示すようにするべきかと。/en/を除いたURLが同じだけど、別の内容の記事ってのは避けた方がよいかと。

AIによるチェック

文体、誤字脱字、用語・表記の統一 ※プロンプトなどを任意で設定して基盤モデルにリクエストを送れる環境が用意されている前提。他用途でも使えるからこれ専用ではなくて用意されているのが理想的かと。(情報流出を防ぐためRAG環境とは分離されている方がいいかも?)

人間によるチェック

AIのチェックで怒られた場合に人の承認でGoとするか。

テスト自動化の流用

UIの崩れが無いか、開発側のテスト自動化でのUIのテストを流用できるかも?コンポーネント使っているから崩れないはずだけど、、、。でも初回のテストだと差分も取りようがないから結局使えないかも。

ナビゲーション

設置場所とURL

原則、ヘッダーやサイドのナビゲーションバーの階層構造と同じ形のURL。 複数のナビゲーションバーのリンク元にはエイリアスを置くイメージ。

URLの更新とリダイレクト設定

URLが階層構造に従うとすると、設置場所を変えたときにURLが変わってしまう。原則一度公開したURLは変えないため、変更元のURLはコンテンツのメタデータなどに記録が残るようにしておいて、自動的にリダイレクトが設定されるようにする。新規ページが過去のURLと重複するような場合の運用は要検討(新しいのが奪う感じでいいと思うけど) リダイレクトがループしないようにチェックも必須。 あと、そのためには記事にはUUIDのようなURLやタイトルなどとは独立したユニークなIDを振るべきかと。

ABテスト

考え中。。。 対象ページのURLは、テスト中の被リンクの可能性を考慮すると、同一である方がいいかも。ただ、設計が複雑になるから考え物。

運用とガバナンス

1ユーザ1アカウント

CMSにSSOできるのが理想的。SCIMができてもいい。所属部署に応じた適切な権限設定。

定期的な更新・非公開化の確認

公開日から確認の実施日までの経過時間で更新をサジェスト可能。 終了したイベントの日程などは、AIに読ませることで、明示的にタグ付けされていない文中であっても識別可能。

バージョン管理とバックアップ

「公開」する際のwebhookなどをトリガーとして、S3などに保存。担当者にはReadOnlyで権限を付けて、確認を許可することも可能。誤削除に備えたバックアップや証跡としても機能。

最後に

最初から全部やる必要は全然なく、基本的にはSaaSのCMSの機能だけで十分かと。追加で機能をlambdaで作ったり、ほかのSaaSを入れたりしてAPIで連携できれば御の字。